In the 3GPP (3rd Generation Partnership Project), there have been discussions about methods for continuing a voice service between different access networks. VCC (Voice Call Continuity) can be cited as one example of them (see Non-Patent Document 1). The VCC is, specifically, realized by using a VCC-AS (Application Server) provided in an IMS (Internet Protocol Multimedia Subsystem).
FIG. 1 is a diagram for explaining the general end-to-end call control scenario of transfer between access domains defined in Non-Patent Document 1 and so on. A mobile terminal B can access a cellular mobile network through cellular wireless communication [3GPP-CS (Circuit Switched)]. The mobile terminal B can also access an IMS network through, for example, an in-house wireless LAN (Local Area Network).
In FIG. 1, for example, when a mobile terminal B on the incoming side moves from an IMS domain to a CS domain, i.e. performing handover, the mobile terminal B starts call setup in the CS domain (step S101-CS). That is, the mobile terminal B sends a SETUP message (call setup message in the CS phone network) to an MSC (Mobile Services Switching Center) 100. For anchoring this call control at a VCC-AS 104, the SETUP message is transferred to a CSCF (Call Server Control Function) 103 through a MGCF (Media Gateway Control Function)/MGW (Media Gateway) 101 (steps S102 and S103) and further transferred from the CSCF 103 to the VCC-AS 104 (step S104).
Then, the VCC-AS 104 sends a SIP UPDATE (session update) message for starting to change call connection or a Re-INVITE (request to establish a re-session) message to the CSCF 103 (step S105). By this message, an MGW IP (Internet Protocol) address indicating a new call connection path and new SDP (Session Description Protocol) information are transmitted to the CSCF 103 from the VCC-AS 104. The SIP UPDATE message or the Re-INVITE message is transferred from the CSCF 103 to a CSCF 105 in a partner-side IMS domain (step S106) and finally transferred to a mobile terminal A being a communication partner (step S107). The mobile terminal A changes a voice packet transfer destination IP address to the transferred MGW IP address. By this, a voice packet transfer path (voice bearer) is switched on an end-to-end basis.
On the other hand, in FIG. 1, when a mobile terminal B moves from a CS domain to an IMS domain, i.e. performing handover, the mobile terminal B starts call setup in the IMS domain (step S101-IMS). That is, the mobile terminal B sends a SIP INVITE (request to establish a session) message to a CSCF 103. This SIP INVITE message is transferred to a VCC-AS 104 from the CSCF 103 (step S104). The VCC-AS 104 sends a SIP UPDATE (session update) message for starting to change call connection or a Re-INVITE (request to establish a re-session) message to the CSCF 103 (step S105). By this message, an IP address of the mobile terminal B indicating a node of a new call connection path and new SDP information are transmitted to the CSCF 103. The SIP UPDATE message or the Re-INVITE message is transferred from the CSCF 103 to a CSCF 105 in a partner-side IMS domain (step S106) and finally transferred to a mobile terminal A being a communication partner (step S107). The mobile terminal A changes a voice packet transfer destination IP address to the transferred IP address of the mobile terminal B. By this, a voice packet transfer path (voice bearer) is switched on an end-to-end basis.
While the above is the scenario of voice service continuity following the mobile terminal handover between the IMS domain and the CS domain, the VCC-AS is also expected to be used in the same manner as in the above when continuing a voice service between the CS domain and a predetermined wireless broadband [e.g. LTE (Long Term Evolution) access or Non-3GPP access].
Non-Patent Document 1: 3GPP TS23.206 V7.5.0 “Voice Call Continuity (VCC) between Circuit Switched (CS) and IP Multimedia Subsystem (IMS)”